Overview

Tightly-scoped fix for the rc.2 GA blocker (B1): @cipherstash/auth was catalog-pinned at 0.41.0 while its six @cipherstash/auth-* platform bindings sat at 0.42.0. Because auth declares those bindings as exact-version optional peer dependencies, the skew made npm nest per-consumer binding copies the hoisted auth package couldn't resolve — so every project-local CLI/SDK install died at startup with Failed to load native binding. The fix bumps auth to 0.42.0 (all seven now in lockstep), bars Dependabot from bumping any of them independently, and adds a CI guard so the skew can't recur.

The root-cause writeup and the reproduction are excellent, and the fix matches the diagnosis exactly.

What's right

• The core change is correct and minimal. pnpm-workspace.yaml catalog @cipherstash/auth: 0.41.0 → 0.42.0; pnpm-lock.yaml re-resolves cleanly to 0.42.0(...bindings@0.42.0) across all three consumers (stack, cli, wizard). Verified all 7 catalog entries now read 0.42.0.
• The Dependabot guard is the right shape. @cipherstash/auth-* correctly wildcard-matches the six bindings without over-matching @cipherstash/auth (listed separately) or unrelated scopes. A partial bump of this set is genuinely never safe, so ignoring the whole family and bumping manually is correct.
• The e2e guard is well-designed. Asserting both authEntries.length === 7 and versions.size === 1 means a future binding added/removed upstream trips the count assertion (forcing a deliberate update), while any version skew trips the set assertion — with a message that prints the offending name@version pairs. It reads the catalog (pnpm-workspace.yaml), which is the single source of truth since every consumer uses catalog:repo. This is the guard the "keep in lockstep" comment always implied but never enforced.
• Docs/process hygiene: load-bearing rationale is now captured in three places (workspace comment, dependabot comment, test comment) rather than the old "for tidiness" framing; changeset present (patch for stack/stash/wizard); the durable upstream fix (auth declaring its bindings as its own optionalDependencies, like the sibling @cipherstash/profile and @cipherstash/protect-ffi) is correctly identified as follow-up rather than attempted here.

Notes — minor, non-blocking

1. Unrelated lockfile churn — please confirm intentional. Beyond the auth lines, the pnpm-lock.yaml diff shifts a @vitest/mocker@3.2.7 peer resolution from @types/node@22.20.1 to @types/node@26.1.1 (and adds a matching snapshot block). It's benign — @types/node@26.1.1 already resolves 21× in the base lockfile, and this only touches a dev/test-only mocker peer, not any runtime dependency — but it's incidental to an auth-alignment PR and unexplained in the description. Worth a sentence confirming it's just re-resolution drift from regenerating the lock, so a reviewer doesn't have to reverse-engineer it.

2. (Optional) The guard covers the catalog, not the lockfile or consumer manifests. That's the correct primary check — the catalog is the source of truth and frozen-lockfile CI keeps the lock honest. No change needed; noting only so the guard's scope is explicit: it would not catch a hand-edited consumer optionalDependencies that bypassed catalog:repo, but nothing in-repo does that today.

Verdict

Correct, well-tested, and the regression guard closes the exact hole that produced the blocker — this is good to merge. The only ask is a one-line confirmation that the @types/node lockfile shuffle (item 1) is intentional re-resolution and not a stray change.

Approved, thanks for this @coderdan.

Approving — the fix is correct, minimal, and well-guarded, and it resolves the rc.2 GA blocker (B1). The catalog lockstep bump, the Dependabot @cipherstash/auth-* ignore, and the new supply-chain e2e guard together close exactly the hole that caused it. My earlier review has the detail; the only open item is the minor, non-blocking ask to confirm the unrelated @types/node lockfile re-resolution is intentional.